Multicast is often used to deliver live media content over a managed IPTV network. For instance, media clients such as a set-top box or web application that receives live television, connects receives live content from acquisition server (sometimes referred to as an AServer) that is coupled with a live television headend. A receiver that receives a multicast live stream is required to receive a full “I” frame (a frame that is not dependent on other frames) before it can start displaying video. “I” frames may appear in the stream periodically (e.g., every two seconds). Since the video cannot be decoded until the “I” frame is received, a user tuning to a new channel may experience a relatively long channel startup time. The multicast live stream typically uses UDP and packet loss occurs from time to time. Since there is no retransmission mechanism for UDP, packet loss may result in serious video quality degradation.
Some managed networks deploy other server(s) coupled to the acquisition server (referred to as a distribution server or sometimes a DServer) to achieve reliable UDP transmission. The DServer receives multicast video from the AServer. The DServer buffers the latest “I” frame data. Upon the receiver submitting a channel change request (e.g., first tuning to a channel or changing the channel from one channel to another), the DServer sends the buffered information to the receiver using Unicast to minimize the wait time before video starts playing. Some implementations call this feature Instant Channel Change (ICC) as it substantially reduces the amount of time to display video upon a channel change. Since the DServer buffers the video, the DServer can also fulfill packet retransmission requests from the receiver when the receiver detects packet loss. For instance, when the receiver detects that a packet has not been received, the receiver may request that packet from the DServer and if the DServer has that packet buffered, the DServer can respond with the packet to the receiver.
DServer implementation faces the problem of scalability issues. A single DServer cannot service too many clients concurrently since all data sent from the DServer to the receiver is Unicast and the amount of data the DServer sends to the client can be significant (at least for the burst of unicast video data when responding to a channel change request), which consumes a significant amount of CPU as well as bandwidth. Load balancing of DServer load is also challenging. For instance, when a popular TV program begins, there can be many channel change requests (or retransmission requests) that are received at the DServer in a short period of time. Given the real time nature of live TV transmission, a long delay is not acceptable. Thus more and more DServers have to be deployed in the cluster which increases cost.